2. Federated Identity (SSO)
Organizations planning to implement identity federation that enables SSO
for users can take one of the following two paths
(architectures):
Both architectures have pros and cons.
2.1. Enterprise identity provider
In this architecture, cloud services will delegate
authentication to an organization’s IdP. In this delegated authentication architecture, the
organization federates identities within a trusted circle of CSP
domains. A circle of trust can be created with all the domains that
are authorized to delegate authentication to the IdP. In this
deployment architecture, where the organization will provide and
support an IdP, greater control can be exercised over user identities,
attributes, credentials, and policies for authenticating and
authorizing users to a cloud service. Figure 1 illustrates the
IdP deployment architecture.
Here are the specific pros and cons of this approach:
Pros
Organizations can leverage the existing investment in
their IAM infrastructure and extend the practices to the cloud.
For example, organizations that have implemented SSO for
applications within their data center exhibit the following
benefits:
They are consistent with internal policies, processes,
and access management frameworks.
They have direct oversight of the service-level
agreement (SLA) and security of the IdP.
They have an incremental investment in enhancing the
existing identity architecture to support federation.
Cons
By not changing the infrastructure to support federation,
new inefficiencies can result due to the addition of life cycle
management for non-employees such as customers.
Most organizations will likely continue to manage employee and
long-term contractor identities using organically developed IAM
infrastructures and practices. But they seem to prefer to outsource
the management of partner and consumer identities to a trusted
cloud-based identity provider as a service partner.
2.2. Identity management-as-a-service
In this architecture, cloud services can delegate authentication
to an identity management-as-a-service (IDaaS) provider. In this
model, organizations outsource the federated identity management technology
and user management processes to a third-party service provider, such
as Ping Identity, TriCipher’s Myonelogin.com, or Symplified.com.
When federating identities to the cloud, organizations may
need to manage the identity life cycle using their IAM system and
processes. However, the organization might benefit from an outsourced
multiprotocol federation gateway (identity federation service) if it
has to interface with many different partners and cloud service
federation schemes. For example, as of this writing, Salesforce.com supports SAML 1.1 and Google Apps supports SAML 2.0. Enterprises accessing
Google Apps and Salesforce.com may benefit from a multiprotocol
federation gateway hosted by an identity management CSP such as
Symplified or TriCipher.
In cases where credentialing is difficult and costly, an enterprise
might also outsource credential issuance (and background
investigations) to a service provider, such as the GSA Managed Service Organization (MSO) that issues
personal identity verification (PIV) cards and, optionally, the certificates on the cards.
The GSA MSO is offering the USAccess management end-to-end solution as a shared
service to federal civilian agencies.
In essence, this is a SaaS model for identity management, where the SaaS IdP
stores identities in a “trusted identity store” and acts as a proxy
for the organization’s users accessing cloud services, as illustrated
in Figure 2.
The identity store in the cloud is kept in sync with the corporate directory
through a provider-proprietary scheme (e.g., agents running on the
customer’s premises synchronizing a subset of an organization’s
identity store to the identity store in the cloud using SSL
VPNs).
Once the IdP is established in the cloud, the organization
should work with the CSP to delegate authentication to the cloud
identity service provider. The cloud IdP will authenticate the cloud
users prior to them accessing any cloud services (this is done via
browser SSO techniques that involve standard HTTP redirection
techniques).
Here are the specific pros and cons of this approach:
Pros
Delegating certain authentication use cases to the cloud
identity management service hides the complexity of integrating
with various CSPs supporting different federation
standards. Case in point: Salesforce.com and Google support
delegated authentication using SAML. However, as of this writing, they support
two different versions of SAML: Google Apps supports only SAML 2.0, and Salesforce.com supports only SAML 1.1.
Cloud-based identity management services that support both SAML
standards (multiprotocol federation gateways) can hide this
integration complexity from organizations adopting cloud
services.
Another benefit is that there is little need for
architectural changes to support this model. Once identity
synchronization between the organization directory or trusted
system of record and the identity service directory in the cloud
is set up, users can sign on to cloud services using corporate
identity, credentials (both static and dynamic), and
authentication policies.
Cons
When you rely on a third party for an identity management
service, you may have less visibility into the service,
including implementation and architecture details. Hence, the
availability and authentication performance of cloud
applications hinges on the identity management service
provider’s SLA, performance management, and availability. It
is important to understand the provider’s service level,
architecture, service redundancy, and performance guarantees of
the identity management service provider.
Another drawback to this approach is that it may not be
able to generate custom reports to meet internal compliance
requirements.
In addition, identity attribute management can also become
complex when identity attributes are not properly defined and
associated with identities (e.g., definitions of attributes,
both mandatory and optional). New governance processes may be
required to authorize various operations (add/modify/remove
attributes) to govern user attributes that move outside the
organization’s trust boundary. Identity attributes will change
through the life cycle of the identity itself and may get out of
sync.
Although both approaches enable the identification and
authentication of users to cloud services, various features and
integration nuances are specific to the service delivery model—SaaS,
PaaS, and IaaS—.
